2038 is The End Of The World As We Know It. Technically it is the end of an epoch, or perhaps The Epoch. The Epoch is the range of dates starting at January 1, 1970 00:00:00 GMT and ending at January 19, 2038 03:14:07 GMT, used by Perl's time(), Java's Date class, and C/C++'s time() (and I suspect others). This past January 9th was the half-way point of The Epoch's usability. (Microsoft Windows and MS-DOS's epochs end in 2048 because they started in 1980, but they use the same 32-bit date storage as The Epoch.)
So why does this matter to me, you ask? Because if you write code that reads or writes dates, that code will fail in 34 years.
34 years is a long time, you may say. I used to think so, too. Then one day I realized that regular expression code I wrote more than 20 years ago was still shipping in a product that shows no signs of being near the end of its lifecycle.
Code for handling dates, whether for reading, writing, or calculating dates, will start failing when it is asked to handle dates beyond the January 19, 2038 03:14:07 GMT lifespan of The Epoch. This doesn't affect just those of us who work on Web applications, although I will be interested to see how weblogs and online newspapers handle 2038 -- I would hate to lose the access to the contributions of my fellow use.perl.org bloggers, Jerry Pournelle, or Dave Winer over a date error.
January 19, 2008 03:14:08 GMT is important, as you cannot add 30 years to that time without exceeding the limits of The Epoch, thereby affecting some mortgage calculations (30-year mortgages are common here in the States). (Long-term bond maturation calculations (among others) will also be affected by the end of The Epoch.) As a practical matter, 30-year mortgage failures from The Epoch should start occurring around February 20, 2008, as you can't use Epoch dates to calculate the last mortgage payment date (if I have performed the calculations correctly). 2008 is only four years away. (There have been 50-year mortgages originated in Japan within the past 15 years -- but there may not be any programs using Epoch dates that had to handle those mortgages.)
January 19, 2018 03:14:08 GMT will also be important here in the States at least, as you cannot add 20 years to that time without exceeding the limits of The Epoch, thereby affecting 20-year mortgage calculations. 2018 is only 14 years away — which should be well within the date range that software engineers (Perl or otherwise) should be considering when creating or updating date-handling code today.
But I Feel Fine (thereby completing the R.E.M. reference), as my new code uses non-Epoch dates. New Perl code will use DateTime, and my latest Java code already uses the Java GregorianCalendar class. (I still need to research date alternatives for C++ and C.) I confess to feeling a little like Ed Yourdon, who (if I remember correctly) started warning about Y2K problems in the early 1990s, long before the problem really caught the attention of software engineers and IT managers.
If your code (old or new) handles dates, you need to be concerned about 2038 ITEOTWAWKI (2038 Is The End Of The World As We Know It). Perl now has DateTime, which looks like it will work well for most date applications. Readers using other languages will need to do some research (except for Java GregorianCalendar, as noted above). Happy date-handling!
-sam
Re:32bit Blogs in 2038?
Dom2 on 2004-07-14T20:16:55
Some OSes such as FreeBSD/sparc are already using 64 bit time_t's I believe. I'm not sure how badly this affects the ability of software to be ported to them. Mind you, I thought the whole point of having a specific type time_t was so that you coudl redefine it... C. Dontcha just love it.-Dom
64bit time_t, heck, 64-bit everything
n1vux on 2005-01-10T16:37:25
32-bit int, just say no.My next two Perls are going to be 64 bit
... really. Bjorn in perl.dbi.user reports "A succesfull 64-bit build of Perl-DBI-DBD:Oracle on IBM AIX 5.2"; I'm going to try building 5.8.6 with DBI and DBD::DB2 shortly. And my other other project is on an Alpha, where the only Perl is 64 bit. (I hope there's a Deb for DBD::MySQL for that platform ;-) Re:32bit Blogs in 2038?
pudge on 2004-07-16T21:41:30
I turn 65 in 2038. So my plan is that I'll be a consultant for the last few years before I retire, rake in a ton of money, and then when the date hits, call it quits.
It worked for the COBOL programmers, right?
I ran into it 10 years ago - in 1994! I had to calculate the date when the client was to be given old age pesion (at 67 years), and sometimes the code failed miserably. It was discovered that it failed whenever the person was born after 1971, as the normal 'time_t' variables overflowed and I therefore assumed that she was very old.
This was i C++, but the solution was quite simple: port the central parts of Date::Calc to C++ and use that as a date-type.
Works a charm, and gives the operations we need.
